One anon in the https://boards.4channel.org/g/thread/73638728 thread made some comments around guix


-------------------------------------------

I'm running Emacs 26 and Emacs-git-master/27 side-by-side right now on guix. You can also run different variants of emacs with different compile options. You can do literally anything and everything, although much of the more advanced stuff is guix-specific. Do read the guile reference manual eventually.

In guix, you can still run unpackaged applicaations like firefox or rimworld. just downlpad the binaries and patchelf their interpreter to /run/current-system-profile/blablabla/ld-..-linux-... and execute as for example...

env LD_LIBRARY_PATH=<library2>.so:<library2>.so:... firefox-bin

check the interpreter with:

file firefox-bin

or

obj-dump firefox-bin

check the libraries you need with

ldd firefox-bin

some programs have peculiar requirements. Do cat /gnu/store/...emacs-25.../bin/emacs and you'll find that the glib-build-system used by the emacs package wraps everything in bin and libexec in a script wrapper (which is why emacs 27 doesnt work by default because pdmp needs to then be unwrapped with a simple snippet). So, if a program has weird dependencies, you can imitate that wrapper.

In particular, I have dependency hell in the gtk versions and libc versions of some of my binary-only programs. First:

guix build gtk@2
> /gnu/store/abcd1234...-gtk-2...

guix build gtk@3
> /gnu/store/xyzz9987...-gtk-3...

Then I write a wrapper script for my programs that does the patchelf and env LD_LIBRARY_PATH stuff for me.

Guix is not too terrible at documentation, but you really need to learn how to use ag or preferably ripgrep and Emacs to rapidly look-up other folks' examples of how they fixed-up weird packages with "scheme/guile snippets". Every time you do guix pull, the guix source code is ofc pulled, so find that folder somewhere in ~/.guix-profile and symlink it to your desktop or something for easy access.

Everything is logical. It's just alien compared to ie ubuntu or even gentoo.

Do note USE flags can be implemented, just no one bothers.

-----------------------------------

I forgot to add something. You will inevitably find yourself wanting to change not only package versions but also the source code of their dependencies. cf the wrapper scripts guix uses as a hack to make some more complicated packages' dependency hell just work, although you can for example run X11 applications through a container with some annoying trickery and thus do away with the script hacks which is where guix is very slowly moving toward.

In particular, iirc you might wish to do:

guix build --replace-source=wine-data=<path-to-git-repository-folder-on-your-computer> wine64-staging

(this is not a real example, but you'll get what I mean after a month of guix use or so.)

You will find this documented in the manual, but it will not cover the particular use case you want here! However, if you open emacs and do m-x guix (emacs-guix is pre-installed as part of the guix source code), a magit-looking gui appears. If you navigate through the gui and install a package (or even only build a package) through it, a guile REPL appears and shows you exactly what sexp did the "install" magic, at which point you'll realize it is the classic unix notions of "install" or "build" that are limiting. Simply put, you'll see that you can do exactly what you want 90% of the time, but you need to write not through the "guix" command but by using guix as a library to a guile sexp; the guix devs have simply not implemented what you want in the cli, but they /have/ already provided a programmatic interface.

As an example of what I mean without actually using guix, a guile scheme (i keep on saying that because technically guile also supports seamless use of javascript and emacs-lisp among other languages, see the guile manual) script might look like:

#!/usr/bin/env <forgot-what-goes-here>
guile -s
!#

(use-modules ... <guix would go here>)

(<do stuff here>)

(<do more stuff here>)

And then you run that like a bash script.

again do read the guile man's first 20 pages.

---------------------------------------------------

one more thing. the unix notion of "service" is not cogent owing to cross-references and temporally-disjoint references ("i need the x screen but the x screen cannot launch without me and the x screen needs a special provided by bob's service but i x must hook into bob exactly before i do or else i will break").

Warch some online video lectures on guix, there are not many. in particular, guix adopted its modern service system only a few years ago, so do look for a tutorial-esque summary on that OR ELSE NOTHING WILL MAKE SENSE and you will inevitably rage.

In other words, watch this video first, it will seem odd but it will make sense over time:

[YouTube] Composing system services in GuixSD or how we came to wonder what a "system service" really is (embed)

You will also find certain packages are horribly difficult to set up on guix. These come in three flavors:

1. Closed-source drivers.

Linux has no notion of a stable in-kernel binary interface. THe guix blog now has a tutorial on building your own kernel, so do read it. Switching kernels is almost as easy as changing the upstream code's URI (see the nonguix channel on gitlab for examples). Historical background (short read, you must read it):

https://github.com/torvalds/linux/blob/master/Documentation/process/stable-api-nonsense.rst

2. Fedora-directory-hierarchy-layout software

This means locations like library paths and the basic /bin /etc
/opt are all hard-coded in closed-source software. The only two examples I know of are Steam and Mathematica (and perhaps also Matlab). The Nix solution is to use a chroot. There are two different ways of solving the issue on guix but I am too lazy to explain and I'm running out of characters.

3. Open-source but NOT open-developed computing infrastructure

Examples:
- Valve's Proton, which is Wine with about 15 other helper utilities mashed in along with it.
- AMD's ROCm

i.e. watch David Airlie rant about ROCm:

[YouTube] But Mummy I don't want to use CUDA - Open source GPU compute (embed)

------------------------------------

I should probably write a blog about this, i am writing way too much....

In reference to point number 3 in the last post, in practice you'll find yourself wanting to switch between radv and amdvlk drivers for example. the open-source but closed-developed amdvlk driver does have a mound of instrumentation information interfaces not found in radv. this is meant for a software dev obviously. archlinux and such can also do this, but guix makes this easy at boot-up (add some new menuoptions in your one-file system configuration) and while you are running (stop x11 service, change drivers, start x11 service). other ways are also possible.

FINALLY, to control the logic behind all of the things you've always wanted to do but never had time for, don't bother making time! Just use a logic programming langauge (a pattern-matching programming style basically)! Scheme has Schelog, which is Prolog accessible as Scheme and implemented entirely in Scheme, see:

https://ds26gte.github.io/schelog/index.html

The sky is the limit.

FINALLY FINALLY, guix does not yet have a notion of caching compilation steps. In other words, interrupting the compilation of some linux kernel and restarting it later does not require a full re-compilation if and only if your follow-up guix command really is recompiling the exact same linux kernel. This makes two operations extremely annoying:

1. Figuring out how to play with packages through your own channel takes forever because the guix pull operation is painfully slow computationally.

2. There is no cache of compilatiom object and no notion of ccache, so changing one tiny compile flag in a package definition or even changing a single dependency thay cannot be "grafted" in guix lingo triggers a full recompilation which can take an eternity. However, you can offload compilation to another machine, just cannot use ccache.


-------------------------------

As one very final aside, you get stuff like flatpak for free in guix. The user on Ubuntu simply downloads Guix's bootatrap tarball, spends 2 minutes setting up their user's guix profile, then has access to all of guix minus of course the shepherd system services bits and the "system reconfigure" command (though the system build and all other commands still work). THe guix environment command is flatpak on steroids, and keeping your stuff updated is a simple

guix install -u (iirc)

or something like this for only emacs packages:

guix install -u --match=emac.*

i have no idea why i wrote this on 4chan.

YOU KNOW KNOW ALL YOU NEED TO KNOW TO JUSTIFY NEVER EVER USING ANYTHING OTHER THAN NIX OR GUIX EVER AGAIN.
